System and method for unified accounting for wireless communication networks

ABSTRACT

The present disclosure provides a system and method for providing unified accounting for a network including GSM, WAIN and WLAN components.

RELATED APPLICATION

This application claims benefit of U.S. Provisional Application No.60/430,510, filed Dec. 2, 2002. Furthermore, this application relates toU.S. application Ser. No. 09/851,681, filed on May 8, 2001, which iscommonly assigned and incorporated herein by reference in its entirety.

BACKGROUND OF THE INVENTION

The present invention relates generally to a communications system and,more particularly, to a method and apparatus for unified accountingacross wireless communication network.

There exists several different accounting methods that users may utilizeto access a wireless communications networks However, no efficientmethod or system exists that provides unified accounting for a varietyof accounting methods.

Therefore, what is needed, is a system and method that provides unifiedaccounting for more than one accounting method utilized for more thanone access method.

SUMMARY OF THE INVENTION

The present disclosure provides a system and method that provide unifiedaccounting across wireless communication networks.

Therefore, in accordance with the previous summary, objects, featuresand advantages of the present disclosure will become apparent to oneskilled in the art from the subsequent description and the appendedclaims taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an IMSI field;

FIG. 2 is a diagram of a user logging into a server using a SIM card;

FIG. 3 is a diagram of a wireless local area network user logging into aserver using a RADIUS user ID and password when the WAIN server is usedas an AC;

FIG. 4 is a message dialog of a wireless user logging into a RADIUSserver; and

FIG. 5 is a diagram of a wireless local area network user logging into aserver using a RADIUS user ID and password when the WAIN server is usedas RADIUS proxy.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present disclosure can be described by the embodiments given below.It is understood, however, that the embodiments below are notnecessarily limitations to the present disclosure, but are used todescribe a typical implementation of the invention. In addition, detailsof a Wireless Access Integrated Node (WAIN) server and architecture canbe found in the patent application Ser. No. 09/851,681, incorporated byreference above.

There are currently two different accounting standards supported bywireless data service providers. The General Packet Radio Service (GPRS)operators comply with European Telecommunications Standard Institute(ETSI) standards while the Wireless Internet Service Provider (WISP)operators comply with Internet Engineering Task Force (IETF) standards.

However, these two standards differ from each other. Some Wireless LocalArea Network (WLAN) users may not have a GPRS subscription associatedwith an International Mobile Subscriber Identity (IMSI) within aSecurity Identity Module (SIM) card. Thus, those WLAN users utilize theIETF accounting standards. Therefore, it is desirable if those userscould use the same GPRS charging and billing system as specified by ETSIstandards.

ETSI accounting complies with Global System for Mobile Communication(GSM) specification 12.15 which utilize Call Data Records (CDRs). TheseCDRs are generated upon reaching certain trigger conditions specified bythe GSM 12.15. Moreover, the IMSI is a user identifier that links theCDR to a particular user. Two types of CDRs are generated, an S-CDR anda G-CDR. The CDR contents are shown in Table 1.

TABLE 1 GPRS CDR Format Presence M = Mandatory C = Con- ditional O =Field Optional Description Record M The field identifies the type of therecord e.g. S- Type (S-CDR/ CDR, G-CDR, M-CDR, S-SMO-CDR and S- G-CDR)SMT-CDR. Network C This field indicates that Packet Data ProtocolInitiated (S-CDR/ (PDP) context is network initiated. The field is PDPG-CDR) missing in case of mobile activated PDP context. Context Anony- CSet to true to indicate anonymous access (and that mous (S-CDR/ theServed IMSI is not supplied) Access G-CDR) Indicator Served M Thisfields contains the international mobile IMSI (S-CDR/ subscriberidentity (IMSI) of the served party. G-CDR) The Client “served” party isused to describe the mobile subscriber involved in the transactionrecorded (e.g. the calling subscriber in case of a mobile initiated PDPcontext.) The structure of the IMSI is defined in GSM 03.03. Served CThis field contains the international mobile IMEI (S-CDR/ equipmentidentity (IMEI) of the equipment G-CDR) served. The Client “served”equipment is used to describe the ME involved in the transactionrecorded (e.g. the called ME in the case of a network initiated PDPcontext.) The structure of the IMEI is defined in GSM 03.03. Serving MThe S-CDR fields contain the single address of GPRS (S-CDR/ current SGSNand GGSN used. Serving G-CDR) Node (SGSN) Address Gateway M The IPaddress of the GGSN used. GPRS (S-CDR/ Support G-CDR) Node (GGSN)Address MS This MS Network Capability field contains the Network MSnetwork capability value of the MS network Capability capabilityinformation element of the served MS on PDP context activation or onGPRS attachment as defined in GSM 04.08. Routing Routing Area at thetime of the record creation. Area Local Location area code at the timeof the record Area creation. Code Cell Cell ID at the time of the recordcreation. Identity Charging M This field is a charging identifier whichcan be ID (S-CDR/ used together with the GGSN address to identify G-CDR)all records produced in SGSN(s) and GGSN involved in a single PDPcontext. Charging ID is generated by the GGSN at PDP context activationand transferred to the context requesting SGSN. At inter-SGSN routingarea update, charging ID is transferred to the new SGSN as part of eachactive PDP context. Different GGSNs allocate the charging IDindependently of each other and may allocate the same numbers. TheCharging Gateway Facility (CGF) and/or BS may check the uniqueness ofeach charging ID together with the GGSN address and optionally (if stillunambiguous) with the record opening time stamp. The GGSN function inthe WS generates an integer in the range of 0..4294967295 unique toitself for every CDR issued. GGSN M The IP address of the GGSN currentlyused. The Address (S-CDR) GGSN address is always the same for an Usedactivated PDP. Access M This field contains the logical Access PointName Point (S-CDR/ (APN) used to determine the actual connected NameNIG-CDR) access point. The APN is comprised of a mandatory networkidentifier and an optional operator identifier (this field is thenetwork identifier). The APN can also be a wildcard, in which case theSGSN selects the access point address. See GSM 09.60 and GSM 03.60 formore information about APN format and access point decision rules. TheAPN is information from the MS or SGSN, that may be used by the GGSN todifferentiate between accesses to different external packet datanetworks using the same PDP Type. APN O This field indicates how theSGSN selected the Selection (S-CDR/ APN to be used. The values and theirmeaning Mode G-CDR) are as specified in GSM 09.60 clause 7.9‘Information elements’. PDP Type M This field defines the PDP type (e.g.X.25, IP, (S-CDR/ PPP, or IHOSS:OSP) (see GSM 09.60 for exact G-CDR)format). Served M This field contains the PDP address of the served PDP(S-CDR/ IMSI. This is a network layer address (e.g. of Address G-CDR)type IP version 4, IP version 6 or X.121). The address for each PDP typeis allocated either temporarily or permanently (see field “DynamicAddress Flag”). Remote O Remote PDP address may be used if PDP type isPDP (G-CDR) X.25. This parameter is not used if the PDP type Address isIP, PPP, or IHOSS:OSP. Itemized volume billing is available per APN.This field contains a list of connected remote PDP addresses. Dynamic CThis field indicates that PDP address has been Address (G-CDR)dynamically allocated for that particular PDP Flag context. Field ismissing if address is static (e.g. part of PDP context subscription).Dynamic address allocation might be relevant for charging (e.g. theduration of PDP context as one resource offered and possible owned bynetwork operator). List of M This list includes one or more containers,which Traffic (S-CDR/ each include the following fields: Data VolumeData G-CDR) Uplink, Data Volume Downlink, Change Volumes Condition andTime Stamp. Data Volume includes the number of octets transmitted duringthe use of packet data services. Change condition defines the reason forclosing the container (see 5.7.1 and 5.7.3), such as tariff time change,Quality of Service (QoS) change or closing the CDR. Change time is atime stamp which defines the moment when the new volume counts arestarted or the CDR is closed. All the active PDP contexts do not need tohave exactly the same time stamp (e.g. due to same tariff time changevariance of the time stamps is implementation and traffic load dependentand is out of the scope of standardization). The first container caninclude the following optional fields: QoS Requested (not in G-CDR) andQoS Negotiated. In the containers that follow, QoS Negotiated is presentif previous change condition is QoS change. For more information, see12.15 page 28. Record M This field contains the time stamp of when theOpening (S-CDR/ record is opened (see GSM 12.05 for exact Time G-CDR)format). Record opening reason does not have a separate field. For G-CDRand M-CDR, it can be derived from the field “Sequence number” i.e.missing field or value one means activation of PDP context and GPRSattachment. For the S- CDR, the field “SGSN change” also needs to betaken into account. Duration M This field contains the relevant durationin (S-CDR/ seconds for PDP contexts (S-CDR, G-CDR, and G-CDR) attachment(M-CDR)). For partial records, this is the duration of the individualpartial record and not the cumulative duration. It should be noted thatthe internal time measurements may be expressed in terms of tenths ofseconds or even milliseconds and, as a result, the calculation of theduration may result in the rounding or truncation of the measuredduration to a whole number of seconds. Whether or not rounding ortruncation is to be used is considered to be outside the scope of thisSpecification subject to the following restrictions: A duration of zeroseconds shall be accepted providing that the transferred data volume isgreater than zero. The same method of truncation/rounding shall beapplied to both single and partial records. SGSN C This field is presentonly in the S-CDR to indicate Change (S-CDR) that this is the firstrecord after an inter-SGSN routing area update. Cause for M This fieldcontains a reason for the release of the Record (S-CDR/ CDR includingthe following: normal release - Closing G-CDR) PDP context release orGPRS detach; partial record generation - data volume limit, time(duration) limit, SGSN change of maximum number of changes in chargingconditions; abnormal termination (PDP or MM context); and managementintervention (request due to O&M reasons). A more detailed reason may befound in the diagnostics field. Diag- O This field includes a moredetailed technical nostics (S-CDR/ reason for the release of theconnection and may G-CDR) contain one of the following: a MAP error fromGSM 09.02; or a Cause from GSM 04.08. The diagnostics may also beextended to include manufacturer and network specific information.098i/8h. Record C This field contains a running sequence number Sequence(S-CDR/ employed to link the partial records generated in Number G-CDR)the SGSN/GGSN for a particular PDP context (characterized with same theCharging ID and GGSN address pair). In the S-CDR, the sequence number isalways started from one after inter- SGSN routing area update (see field“SGSN change”). The Record Sequence Number is missing if the record isthe only one produced in the SGSN/GGSN for the PDP context (e.g. inter-SGSN routing area update can result to two S- CDRs without sequencenumber and field “SGSN update” present in the second record). Node ID OThis field contains an optional operator (S-CDR/ configurable identifierstring for the node which G-CDR) generated the CDR. Record O The fieldenables network operators and/or Extensions (S-CDR/ manufacturers to addtheir own extensions to the G-CDR) standard record definitions. Thisfield contains a set of “management extensions” as defined in CCITTX.721. Local O This field includes a unique record number Record (S-CDR/created by this node. The number is allocated Sequence G-CDR)sequentially including all CDR types. The Number number is unique withinone node, which is identified either by field Node ID or by recorddependent node address (SGSN address, GGSN address, Recording Entity).The field can be used to identify missing records in post processingsystem. Access M This field contains the logical APN used to Point(S-CDR) determine the actual connected access point. The Name OI APN iscomprised of a mandatory network identifier and an optional operatoridentifier (this field is the operator identifier). APN can also be awildcard, in which case SGSN selects the access point address. (see GSM09.60 and GSM 03.60 for more information about APN format and accesspoint decision rules.) The APN is information from the MS or SGSN, thatmay be used by the GGSN to differentiate between accesses to differentexternal packet data networks using the same PDP Type.

On the other hand, the accounting standard specified by the IETF is aRemote Authentication Dial-In User Server/Service (RADIUS) accountingstandard defined by Request for Comment (RFC) 2866. RADIUS accountingrecords, like the CDR counterparts, are generated upon reaching certaintriggers. In addition, a field named “User-Name” is an user identifierthat links the RADIUS accounting record to a particular user. Listedbelow is a table with the RADIUS attributes.

TABLE 2 RADIUS Accounting Record RADIUS Element Description NAS-IP- Thisattribute indicates the identifying IP address of the server Addresswhich is requesting authentication of the user. This attribute must bepresent if NAS-Identifier is not present. This attribute is configurableat the WAIN server. NAS-Port- This attribute indicates the type of thephysical port of the Type NAS which is authenticating the user. It isonly used in Access-Request packets. The value of the NAS-Port-Type is19 to represent 802.11. User- This attribute indicates the name of theuser to be Name authenticated. This is the user credential collectedfrom the web login page. Framed- This attribute indicates the IP addressassigned to the user. IP- Address Acct- This attribute is a uniqueAccounting ID to make it easy to Session- match start and stop recordsin a log file. The start, stop, and ID interim records for a givensession have the same Acct- Session-Id. An Accounting-Request messagehas an Acct-Session-Id. This attribute is generated by the WAIN serverwhen it sends Accounting Request (Acct-Status-Type=Start) message. Acct-This attribute indicates whether this Accounting Request Status- marksthe beginning of the user service (Start), interim Type (Interim), orthe end (Stop). The WAIN server supports the following values: Start;Stop; and Interim. Acct- This attribute indicates how the session wasterminated, Ter- and can only be present in Accounting-Request recordswhere minate- the Acct-Status-Type is set to Stop. The WAIN server Causesupports the following values: Session Timeout (5); User Request (1);Lost Service (3); Lost Carrier (2); and NAS Reboot (11). ‘SessionTimeout’ indicates that the expiry of Session-Timeout values received inAccounting Request (Acct-Status-Type=Stop). ‘User Request’ indicates theuser has logged out. ‘Lost Service’ indicates there was a problemcommunicating with the RADIUS server or RADIUS accounting server. ‘LostCarrier’ indicates that the server is no longer able to communicate withthe subscriber. ‘NAS Reboot’ indicates that the server has encountered acommunication problem with internal software modules. Event- Thisattribute is included in an Accounting Request message Time- to recordthe time that this event occurred on the NAS, in stamp seconds sinceJan. 1, 1970 00:00 UTC. Acct- This attribute indicates how many octetshave been received Input- from the port over the course of this servicebeing provided, Octets and is sent in Accounting-Request records wherethe Acct- Status-Type is set to Stop or Interim. Acct- This attributeindicates how many octets have been sent to the Output- port in thecourse of delivering this service, and is sent in OctetsAccounting-Request records where the Acct-Status-Type is set to Stop orInterim. Acct- This attribute indicates how many packets have beenreceived Input- from the port over the course of this service beingprovided to Packets a Framed User, and is sent in Accounting-Requestrecords where the Acct-Status-Type is set to Stop or Interim. Acct- Thisattribute indicates how many packets have been sent to Output- the portin the course of delivering this service to a Framed Packets User, andis sent in Accounting-Request records where the Acct-Status-Type is setto Stop or Interim. Acct- This attribute indicates how many seconds theuser has Session- received service, and can only be present inAccounting- Time Request records where the Acct-Status-Type is set toStop or Interim. Acct- This attribute indicates how many seconds theclient has been Delay- trying to send the accounting message, and can besubtracted Time from the time of arrival on the server to find theapproximate time of the event generating this Accounting Requestmessage. (Network transit time is ignored.) It is sent in all AccountingRequest message. Class This attribute is available to be sent by theserver to the client in an Access Accept message, and is sent unmodifiedby the client to the accounting server as part of the Accounting Requestmessage if accounting is supported. VSA This Attribute is available toallow vendors to support their (Vendor own extended Attributes notsuitable for general usage. Specific However, this attribute must notaffect the operation of the Attribute) RADIUS protocol. Servers notequipped to interpret the vendor-specific information sent by a clientshould ignore it (although it may be reported). Clients which do notreceive desired vendor-specific information should make an attempt tooperate without it, although they may do so (and report they are doingso) in a degraded mode.

The system and method of the present invention uses RADIUS accountingrecords to trigger GPRS CDR generation for those WLAN users that do nothave GPRS account. The system of the present invention maps theparameters generated for a RADIUS Accounting-Request to a CDR. However,the CDR generation triggers remain the same. This new accounting systemidentifies the CDRs for the WLAN users by an IMSI which does notcurrently exist in the IETF domain. The accounting system of the presentinvention establishes a method by which a virtual IMSI is generated forthe WLAN users based on certain rules. The virtual IMSI is thentransferred to a WAIN Server and used in the CDR generation.

Now referring to FIG. 1, the IMSI 100, as defined by the ETSI standard,contains three fields: the Mobile Network Code (MNC) 102; the MobileCountry Code (MCC) 104; and the Mobile Subscriber Identity Number (MSIN)106. The MCC 104 is defined as 3 digits (Octets), the MNC 102 is definedas 2 or 3 digits (Octets), and the MSIN 106 is defined as 9 or 10 digits(Octets) for a total of 15 digits (Octets).

The new accounting system of the present invention maps the User-Namefield in the RADIUS Account Record to the IMSI field in the CDR.However, the MSIN field in the IMSI, unlike the MNC and MCC fields, isassigned by the operator and is unique within its network. For eachRADIUS user, a Virtual IMSI (V-IMSI) is defined to provide a one-to-onemapping to its User-Name. Although the V-IMSI is of the same format asthe IMSI, it is used internally in the operator's network foridentifying accounting records for WLAN users who do not have the GPRSsubscription and IMSI assignment.

To identify the WLAN accounting and to avoid any conflict with astandard IMSI used in the accounting system, a special MSIN (V-MSIN)encoding is used for the V-IMSI. For example, the first 3 digits of theMSIN may be set to zero and the remaining digits used to identityindividual WLAN users: V-MSIN=000XXXXXXX. Whatever mapping is used isknown to both the RADIUS authentication server and the accountingsystem. However, other methods can also be used to generate a V-IMSI.

First referring to FIG. 2, a method of a SIM user logging into GPRSnetwork will be described. The process a GPRS user usually follows isthat the client 200 initiates communications with an access point 202that is connected to a WAIN server 204. The WAIN server 204 thenauthenticates the client 200 by the client's SIM card through thesignaling gateway 206 by sending an Authorization Info Request using theSIM card's IMSI. The Authorization Info Request is sent to the HomeLocation Register (HLR) 208 to check to see if the user is authorized touse the GPRS network. An Authorization Info Acknowledge message is sentback to the WAIN server 204 through the signaling gateway 206 if theuser has authorization to use the GPRS network. CDR's are then generatedat the WAIN server 204 with details of the user's service usage and sentto the CG 210 via a standard Ga interface and then to the Billing System212. Each GPRS CDR is generated in standard ASN.1 format for the user200 at the WAIN Server 204.

On the other hand, WLAN-only users do not have an IMSI and therefore cannot use conventional GPRS CDRs. However, the present invention uses theRADIUS server to create a V-IMSI. The system then uses RADIUS messagesto transport the V-IMSI from the RADIUS server to the WAIN server 204.

In the present embodiments, the WAIN Server 200 is used in two differentconfigurations. One method uses the WAIN server as an Access Controller(AC) and the other method use the WAIN server as merely a RADIUS proxyand not an AC.

Now turning to FIG. 3, the client 200 initiates communications with theaccess point connected to a WAIN server 204 as in the previous figure.However, the WAIN server 204 then communicates with a RADIUS server 300to authenticate the WLAN-only user 200. Once the RADIUS user issuccessfully authenticated, the RADIUS Server 300 creates a V-IMSI forthe WLAN-only user 200. The V-IMSI is then passed to the WAIN Server 204in a Class attribute or a VSA of a RADIUS Access Accept message. Thechoice of the Class attribute or the VSA to be used for the V-IMSI isdetermined dynamically by the WAIN Server 204 in this embodiment.

As the user 200 logs out or the session is discontinued, the new RADIUSand GPRS ASN.1 formatted (GSM 12.15) combined accounting records arecreated into a CDR. In addition, the V-IMSI is inserted into every oneof these CDRs. These CDRs are then collected by the existing GPRSCharging Gateway 210 and forwarded to the Billing System 212. The userinformation is then recovered from the V-IMSI in the CDRs and used foraccounting purposes.

In addition, if the V-MSIN is chosen carefully, the V-IMSI can be laterconverted to a valid IMSI if the WLAN-only user subscribes to anintegrated GPRS+WLAN service. The same IMSI can then be used for bothGPRS and WLAN authentication and accounting.

In the present embodiment, the use of the Class attribute or the VSA forthe V-IMSI is optional. However, the CDR generation based on the V-IMSIis dependent upon its presence in the Access Accept message from theRADIUS server 300. The WAIN Server 204 first checks for the presence ofthe VSA in the proper IMSI format. If the VSA is present in the properformat, then it is used; otherwise, the Class attribute is checked forthe V-IMSI. If the V-IMSI is not present in the Access Accept message,the CDR is not generated. In this embodiment, if the coding of theV-IMSI received is in any other format besides the one specified below,the user will not be logged in.

Now turning to FIG. 4, a message exchange is described. The messagesflow from a Client 400 to a WAIN Charging Manager (WCM) 402, a WAINSystem Manager (WSM) 404 and a RADIUS Client (RC) 406 within a WAINserver (not shown) and to a RADIUS Server (RS) 408. In this embodiment,the interface between the WCM 402 and the WSM 404 is the same as it isfor conventional RADIUS accounting records. However, the interfacebetween the RC 406 and the WSM 404 is enhanced to carry the V-IMSI.

A summary of the VSA format is shown below. The fields are transmittedfrom left to right.

Type: 26 for Vendor-Specific.Length: =21 (6 fixed bytes+15 ASCII Characters)Vendor-Id: The high-order octet is 0 and the low-order 3 octets are theSMI Network Management Private Enterprise Code of the Vendor in networkbyte order, as defined in the Assigned Numbers 13448.String: The String field is one or more octets. The actual format of theinformation is site or application specific, and a robust implementationshould support the field as undistinguished octets. It should be encodedas a sequence of vendor type/vendor length/value fields, as follows:

Vendor Type: 0Vendor Length: 15 (the length of the “Attribute-Specific” field)Attribute-Specific: The Attribute-Specific field is coded as an ASCIIstring of maximum size 15 representing the V-IMSI as following:

The message exchange detailing a client logging into the GPRS network isnow described. First, the Client 400 sends a Login-Request to the RC 406as depicted by 410. The RC 406 then sends an Access-Request to the RS408 as depicted by 412. The RS 408 responds with an Access-Accept withthe Class or VSA attribute containing the V-IMSI value in ASCII formatas depicted by 414. The Client 400 then Deactivates or Logs out asdepicted by 420.

Although the WCM 402, the WSM 404 and the RC 406 are shown as separatemodules in this embodiment, they can combined within a single entity.For example, the WAIN server, can implement each of the modules withinthe server itself.

Now details of the second method wherein the WAIN Server 500 acts as aRADIUS proxy 500 and not as an AC is described in relation to FIG. 5. Inthis embodiment, the AP 202 is the AC (or an external Access Controllerexists). Therefore, the WAIN Server 500 acts as a RADIUS proxy 500 forthe RADIUS messages from the AP 202. All the messages shown in FIG. 3between the WAIN Server 204 and the RADIUS Server 300 are exchangedbetween the RADIUS Server 300 and the AP 200 in this figure.

Once the RADIUS user 200 is successfully authenticated, the RADIUSServer 300 passes the V-IMSI to the AP 202 in a Class or a VSA attributeof the RADIUS Access Accept message. The AP 202 conveys the receivedV-IMSI to the WAIN Server 500 in the Class attribute or the VSA ofaccounting messages (e.g. Accounting Start, Accounting Stop and InterimUpdate). The choice of the Class attribute or the VSA to be used forV-IMSI is determined dynamically by the WAIN Server 500 in thisembodiment also.

As the user logs out or the session is discontinued, the RADIUS and GPRSASN.1 formatted (GSM 12.15) accounting records are created in CDRs forthe RADIUS user 200. As in the previous embodiment, the V-IMSI for theRADIUS user 200 is inserted in every CDR. These CDRs are then collectedby the existing GPRS Charging Gateway 210 and forwarded to the BillingSystem 212. The user information is then recovered from the V-IMSI inthe CDRs and used for accounting purposes. Moreover, partial CDRs inthis embodiment are tied to the Interim Update message. When the WAINServer 500 receives an Interim Update message, it generates a partialCDR. This method also depends upon the support of the Class attribute orthe VSA by the AC 202 and its ability to generate RADIUS accountingrecords for the WAIN server 500.

Moreover, although only single entities of the CG 210, HLR 208, andRADIUS Server 300, are shown in this embodiment, multiple entities foreach node can be implemented and handled with the architecture of thepresent invention.

In addition, in order to convert the RADIUS messages into the GPRS CDRformat to form a combined RADIUS/GPRS CDR, a parameter mapping is usedby the present invention. In this embodiment, the CDR is generated bygetting required parameters in real time and then writing them in theCDR. Some of the parameters are gathered from the RADIUS messages whileothers are generated internally by the WAIN Server or read from aconfiguration file. The RADIUS accounting record is also generated andexists for V-IMSI users. Table 3 below shows the RADIUS elementscorrelation with the CDR elements.

TABLE 3 Correlation of RADIUS elements to CDR dynamically from RADIUSMessages. RADIUS GPRS CDR Element Description Element DescriptionNetwork This attribute indicates N/A N/A Access the identifying IPaddress Server of the server which is (NAS)-IP- requestingauthentication Address of the user. This attribute must be present ifNAS- Identifier is not present. This attribute is configurable at theWAIN server. NAS-Port- This attribute indicates N/A N/A Type the type ofthe physical port of the NAS which is authenticating the user. It isonly used in Access- Request packets. The value of the NAS-Port- Type ispopulated as 19 to represent 802.11. User- This attribute indicatesServed This fields contains the Name the name of the user to IMSI IMSIof the served be authenticated. This is party. The Client the usercredential “served party” is used collected from the web to describe themobile login page. subscriber involved in the transaction record- ed(e.g. the calling subscriber in case of a mobile initiated PDP context).Framed- This attribute indicates Served This field contains the IP- theIP address assigned PDP PDP address of the Address to the user. Addressserved IMSI. This is a network layer address (e.g. of type IP version 4,or IP version 6). Acct- This attribute is a unique Charging This fieldis a charging Session- Accounting ID to make it ID identifier which canbe ID easy to match start and used together with stop records in a logfile. GGSN address to The start, stop, and identify all records interimrecords for a produced in the given session have the SGSN(s) and thesame Acct-Session-Id. GGSN involved in a An Accounting-Request singlePDP context. message has an Acct- Charging ID is Session-Id. Thisattribute generated by the is generated by the GGSN at PDP context WAINserver when it activation and sends an Accounting transferred to acontext Request (Acct-Status- requesting SGSN. At Type=Start) message.inter-SGSN routing area updates, the charging ID is transferred to thenew SGSN as part of each active PDP context. Acct- This attributeindicates N/A N/A Status- whether this Accounting Type Request marks thebeginning of the user service (Start), interim (Interim), or the end(Stop). The WAIN server supports the following values: Start; Stop; andInterim. Acct- This attribute indicates Cause This field contains a Ter-how the session was for reason for the release minate- terminated, andcan only Record of the CDR including Cause be present in Closing/ thefollowing: normal Accounting-Request Diagnostic release - PDP contextrecords where the release or GPRS Acct-Status-Type is set detach;partial record to Stop. The WAIN generation - data server supports thevolume limit, time following values: (duration) limit, SGSN SessionTimeout (5); change of maximum User Request (1); number of changes inLost Service (3); charging conditions; Lost Carrier (2); and abnormaltermination NAS Reboot (11). (PDP or MM context); ‘Session Timeout’ andmanagement indicates that the expiry intervention (request ofSession-Timeout due to O&M reasons). values received in A more detailedreason Accounting Request may be found in the (Acct-Status-Type=Stop).diagnostics field. ‘User Request’ indicates the user has logged out.‘Lost Service’ indicates there was a problem communicating with theRADIUS server or RADIUS accounting server. ‘Lost Carrier’ indicates thatthe server is no longer able to communicate with the subscriber. ‘NASReboot’ indicates that the server has encountered a communicationproblem with internal software modules. Event- This attribute isincluded Record This field contains the Time- in an Accounting Openingtime stamp when the stamp Request message to Time record is opened (seerecord the time that this GSM 12.05 for exact event occurred on theformat). NAS, in seconds since Jan. 1, 1970 00:00 UTC. Acct- Thisattribute indicates List of This list includes one Input- how manyoctets have Traffic or more containers, Octets been received from theData which each include the port over the course of Volumes: followingfields: Data this service being Data Volume Uplink, Data provided, andis sent in Volume Volume Downlink, Accounting-Request Downlink ChangeCondition and records where the Acct- Time Stamp. Data Status-Type isset to Stop Volume includes the or Interim. number of octets transmittedduring the use of packet data services. Acct- This attribute indicatesList of This list includes one Output- how many octets have Traffic ormore containers, Octets been sent to the port in Data which each includethe the course of delivering Volumes: following fields: Data thisservice, and is sent Data Volume Uplink, Data in Accounting-RequestVolume Volume Downlink, records where the Acct- Uplink Change Conditionand Status-Type is set to Stop Time Stamp. Data or Interim. Volumeincludes the number of octets transmitted during the use of packet dataservices. Acct- This attribute indicates N/A N/A Input- how many packetshave Packets been received from the port over the course of this servicebeing provided to a Framed User, and is sent in Accounting-Requestrecords where the Acct- Status-Type is set to Stop or Interim. Acct-This attribute indicates N/A N/A Output- how many packets have Packetsbeen sent to the port in the course of delivering this service to aFramed User, and is sent in Accounting-Request records where the Acct-Status-Type is set to Stop or Interim. Acct- This attribute indicatesDuration This field contains the Session- how many seconds the relevantduration in Time user has received service seconds for PDP for, and canonly be contexts (S-CDR, G- present in Accounting- CDR). For partialRequest records where records, this is the the Acct-Status-Type isduration of the set to Stop or Interim. individual partial record andnot the cumulative duration. Acct- This attribute indicates N/A N/ADelay- how many seconds the Time client has been trying to send theaccounting message, and can be subtracted from the time of arrival onthe server to find the approximate time of the event generating thisAccounting Request message. (Network transit time is ignored.) It issent in all Accounting Request message. VSA This Attribute is N/A N/Aavailable to allow vendors to support their own extended Attributes notsuitable for general usage. However, this attribute must not affect theoperation of the RADIUS protocol. Servers not equipped to interpret thevendor- specific information sent by a client ignore it (although it maybe reported). Clients which do not receive desired vendor-specificinformation should make an attempt to operate without it, although theymay do so (and report they are doing so) in a degraded mode. Class Thisattribute is available N/A N/A to be sent by the server to the client inan Access Accept message, and SHOULD be sent unmodified by the client tothe accounting server as part of the Accounting Request message ifaccounting is supported.

The parameters that the WAIN Server generates internally or read fromthe configuration file are listed below in Table 4 along with the sourceinformation.

TABLE 4 Source of the CDR elements that cannot be derived from RADIUSmessages Presence M = Mandatory C = Con- ditional O = Field OptionalDescription Source Record M The field identifies the type of the WAINType (S-CDR/ record e.g. S-CDR, G-CDR, Charging G-CDR) M-CDR, S-SMO-CDRand Manager S-SMT-CDR. GGSN M The IP address of the GGSN used. Address(S-CDR/ G-CDR) SGSN M The IP address of the SGSN. Address (S-CDR/ G-CDR)Routing Routing Area at the time of the Network Area record creation.Management Local O Location area code at the time Network Area Code(S-CDR) of the record creation. Management Cell O Cell ID at the time ofthe record Network Identity (S-CDR) creation. Management GGSN M The IPaddress of the GGSN WAIN.CFG Address (S-CDR) currently used. The GGSNaddress Used is always the same for an activated PDP. Access M Thisfield contains the logical APN Network Point (S-CDR/ used to determinethe actual Management NameNI G-CDR) connected access point. APNcomprises of mandatory network identifier and optional operatoridentifier (This field is the network identifier). APN can also be awildcard, in which case SGSN selects the access point address. See GSM09.60 and GSM 03.60 for more information about APN format and accesspoint decision rules. The APN is information from the MS or SGSN, thatmay be used by the GGSN to differentiate between accesses to differentexternal packet data networks using the same PDP Type. APN O This fieldindicates how the SGSN Hard Coded Selection (S-CDR/ selected the APN tobe used. The as “MS or Mode G-CDR) values and their meaning are asNetwork specified in GSM 09.60 clause 7.9 Provided ‘Informationelements’. Subscription Verified” PDP Type M This field defines the PDPtype, Hard Coded (S-CDR/ e.g. X.25, IP, PPP, or as “IP” G-CDR) IHOSS:OSP(see GSM 09.60 for exact format). Dynamic C This field indicates thatPDP Hard Coded Address (G-CDR) address has been dynamically as “True”Flag allocated for that particular PDP context. Field is missing ifaddress is static (e.g. part of PDP context subscription). Dynamicaddress allocation might be relevant for charging (e.g. the duration ofPDP context as one resource offered and possibly owned by networkoperator). Node ID O This field contains an optional Network (S-CDR/operator configurable identifier Management G-CDR) string for the nodewhich generated the CDR. Local O This field includes a unique recordWAIN Record (S-CDR/ number created by this node. The Charging SequenceG-CDR) number is allocated sequentially Manager Number including all CDRtypes. The number is unique within one node, which is identified eitherby field Node ID or by record dependent node address (SGSN address, GGSNaddress, Recording Entity). The field can be used to identify missingrecords in a post processing system. Access O This field contains thelogical Network Point (S-CDR) APN used to determine the actualManagement Name OI connected access point. APN comprises of mandatorynetwork identifier and optional operator identifier (this field is theoperator identifier). APN can also be a wildcard, in which case SGSNselects the access point address. See GSM 09.60 and GSM 03.60 for moreinformation about APN format and access point decision rules. The APN isinformation from the MS or SGSN, that may be used by the GGSN todifferentiate between accesses to different external packet datanetworks using the same PDP Type. Record C This field contains a runningWAIN Sequence (S-CDR/ sequence number employed to link Charging NumberG-CDR) the partial records generated in the Manager SGSN/GGSN for aparticular PDP context (characterized with same the Charging ID and GGSNaddress pair). In the S-CDR, the sequence number is always started fromone after inter-SGSN routing area update, see field “SGSN change”. TheRecord Sequence Number is missing if the record is the only one producedin the SGSN/GGSN for the PDP context (e.g. inter-SGSN routing areaupdate can result to two S-CDRs without sequence number and field “SGSNupdate” present in the second record).

Using both tables 3 and 4, the system of the present invention createsthe new combined RADIUS/GPRS CDRs for the WLAN-only users that conformwith the GPRS accounting format. Thus, the present invention creates aunified accounting system for both WLAN-only users as well as GPRSusers. In addition, the system of the present invention provides amethod for WLAN-only users to later convert their V-IMSI into apermanent IMSI for GPRS use.

It is understood that several modifications, changes and substitutionsare intended in the foregoing disclosure and in some instances somefeatures of the invention will be employed without a corresponding useof other features. Accordingly, it is appropriate that the appendedclaims be construed broadly and in a manner consistent with the scope ofthe invention.

1. A system for providing unified accounting for a hybrid wirelessnetwork, the system comprising: a mobile client; an access pointconnected to the mobile client; a wireless integrated node connected tothe access point; a RADIUS server connected the wireless integratednode, wherein the RADIUS server authenticates the mobile client and alsoprovides an identity number for the mobile client; a charging gatewayconnected to the wireless integrated node; a billing system connected tothe charging gateway, wherein the billing system provides a bill forusage of the wireless network by the mobile client and wherein the billutilizes the mobile client's identity number.
 2. The system of claim 1further including a signaling gateway and a home location register forauthenticating the mobile client.
 3. The system of claim 1 wherein theidentity number is an International Mobile Subscriber Identity (IMSI)number.
 4. The system of claim 3 wherein the IMSI is a temporary numberonly.
 5. The system of claim 3 wherein the IMSI is transformed to apermanent number for use by the mobile client.
 6. The system of claim 1further including a call detail record utilizing the identity number toproduce the bill for the mobile client.
 7. The system of claim 1 furtherincluding a means to combine RADIUS elements with a call detail record.8. A method of producing unified bill for a hybrid wireless network, themethod comprising: authenticating a mobile client through an accesspoint and a wireless integrated node by a RADIUS server; providing anidentity number to the mobile client upon authentication; accessing thenetwork to utilize resources by the mobile client; producing billingrecords utilizing the identity number for the resources utilized by themobile client, wherein the billing records are stored in a billingsystem for non-RADIUS mobile clients.
 9. The method of claim 8 furtherincluding authenticating a second mobile client through a signalinggateway and a home location register.
 10. The method of claim 8 whereinthe identity number is an International Mobile Subscriber Identity(IMSI) number.
 11. The method of claim 8 wherein the IMSI is a temporarynumber only.
 12. The method of claim 8 wherein the IMSI is transformedto a permanent number for use by the mobile client.
 13. The method ofclaim 8 wherein the billing record is a call detail record.
 14. Themethod of claim 8 further including combining RADIUS elements with acall detail record.
 15. A method of producing unified bill for a hybridwireless network, wherein the network includes EuropeanTelecommunications Standard Institute (ETSI) elements and InternetEngineering Task Force (IETF) elements, the method comprising:authenticating a mobile client through an access point and a wirelessintegrated node by a RADIUS server; providing an International MobileSubscriber Identity (IMSI) number to the mobile client uponauthentication; accessing the network to utilize resources by the mobileclient; producing call detail records utilizing the IMSI number for theresources utilized by the mobile client, wherein the billing records arestored in a ETSI billing system.
 16. The method of claim 15 furtherincluding authenticating a second mobile client through a signalinggateway and a home location register.
 17. The method of claim 15 whereinthe IMSI is a temporary number only.
 18. The method of claim 15 whereinthe IMSI is transformed to a permanent number for use by the mobileclient.
 19. The method of claim 15 further including combining RADIUSelements with the call detail record.